perm filename FACTS[RDG,DBL]1 blob
sn#537644 filedate 1980-09-25 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00029 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 Representing various things in RLL
C00007 00003 ***** Fact # 1.*****
C00010 00004 ***** Fact # 2.*****
C00014 00005 ***** Fact # 3.*****
C00020 00006 ***** Fact # 4.*****
C00023 00007 ***** Fact # 5.*****
C00026 00008 ***** Fact # 6.*****
C00028 00009 ***** Fact # 7.*****
C00030 00010 ***** Fact # 8.*****
C00032 00011 ***** Fact # 9.*****
C00034 00012 ***** Fact # 10.*****
C00039 00013 ***** Fact # 11.*****
C00043 00014 ***** Fact # 12.*****
C00044 00015 ***** Fact # 13.*****
C00046 00016 ***** Fact # 14.*****
C00048 00017 ***** Fact # 15.*****
C00049 00018 ***** Fact # 16.*****
C00050 00019 ***** Fact # 17.*****
C00052 00020 ***** Fact # 18.*****
C00055 00021 ***** Fact # 19.*****
C00056 00022 ***** Fact # 20.*****
C00057 00023 ***** Fact # 21.*****
C00061 00024 ***** Fact # 22.*****
C00064 00025 ***** Fact # 23.*****
C00065 00026 ***** Fact # 24.*****
C00069 00027 ***** Fact # 25.*****
C00072 00028 ***** Fact # 26.*****
C00074 00029 ***** Fact # 27.*****
C00075 ENDMK
C⊗;
Representing various things in RLL
Comments:
There are several obvious problems with showing the set of symbols which
we claim "represent" some fact. First, these symbols are semantically
meaningful only with respect to some interpreter. For a system as
versatile as RLL, the same unit may have many "meanings", depending on
which interpreter is being used -- and this decision is based largely on
the second issue: determining what problem or type of problem (e.g.
answering questions, or performing deductions,) we are trying to solve.
(As an extreme example, any of these systems could claim the quoted string
of characters represents each of these statements; and if their only use
was as examples of English words, this would be quite adequate.)
In RLL, this is not as much a problem as it is in other systems, as things
like the interpreter are themselves explicitly represented. In the
examples which follow, I will try to indicate the question this fact is
trying answer, and provide some idea of the interpreter which would be
involved.
Notation:
1. "U:S" refers to value of the S slot of the unit, U.
2. A unit will be shown as
TheUnit
Slot-1: Value-1
Slot-2: Value-2
: :
Slot-N: Value-N
where Slot-i is the name of a slot, whose value is Value-i. (i.e.
TheUnit:Slot-i = Value-i). This unit, TheUnit, may also have other slots not
shown.
3. Specifying some Value-i using the form "[...]" means
I am writing an easy to read description, rather than one this RLL would actually
be able to understand.
4. Units of the form ___#0032 are used to indicate an arbitrarily named
(ala GENSYMed) unit,
whose interpretation should be clear from information found on this unit.
Naming convention:
Any--- refers to the class of ---'s (eg AnyBuilding)
Typical--- refers to a typical member of such a class (eg the facts
stored on TypicalBuilding are defaults for what to expect for buildings
in general.)
My--- refers to a syntactic slot.
References:
[Greiner] - "RLL-1, A Representation Language Language", HPP-Memo-9, September 1980
[Lenat, Hayes-Roth, Klahr] - "Cognitive Economy", 6-IJCAI
[Stefik] - PhD Thesis, Stanford University, June 1979.
***** Fact # 1.*****
1. M6-3 feeds into M6-2.
Q: What does M6-3 feed into?
Solution: (GetValue 'M6-3 'FeedsInto), which returns M6-2.
Start with units representing M6-3 and M6-2 (each of which is a member of
AnyManhole); and then set the value of the FeedsInto slot of M6-3 to be
the value of M6-2 -- i.e. M6-3:FeedsInto ← M6-2.
M6-3
Isa: (AnyManhole)
FeedsInto: (M6-2)
M6-2
Isa: (AnyManhole)
FeedsFrom: (M6-3)
AnyManhole
Examples: (M6-2, M6-3, ...)
Description: This represents the class of all manholes.
We additionally must have a unit to represent the "FeedsInto" type of
slot. This too is easy - and this bundle of knowledge holds facts like
The value of x:FeedsInto must be a list of manholes, the only x for which
x:FeedsInto is defined is a manhole, and that if x:FeedsInto = y, then
y:FeedsFrom = x (i.e. FeedsInto:Inverse = FeedsFrom).
FeedsInto
Isa: (AnySlot)
Description: This slot maps from manholes to manholes.
Inverse: FeedsFrom
Definition: (λ (u ) [Find the pipe, P, to which this manhole connects.
See which pipes, p-i, this P connects to.
Return the list m-i, where each m-i is connected
to pipe p-i.]
Note - the definition of a slot indicates how to deduce its value -- i.e.
S:Definition is a function, F, whose value, (F u), is the value to fill
u:S.
***** Fact # 2.*****
2. All permanent storage tanks are diked.
[Question: Is this to say by definition all permanent storage tanks are diked,
or that they just happen to be?
I wil assume the latter: ]
A quick and dirty solution is:
AnyPermanentStorageTank
Description: This represents the class of all permanent storage tanks
TypicalExample: TypicalPermanentStorageTank
SubClass: AnyStorageTank
TypicalPermanentStorageTank
Description: This represents a typical permanent storage tanks --
its values are default values for p.s.t.'s in general
TypicalExampleOf: AnyPermanentStorageTank
Diked?: T
[Note that the Description, TypicalExample and TypicalExampleOf slots are already
defined in RLL; and I'm assuming the boolean value "Diked?" slot was already in
existence when this question was posed.]
This solution does require the existence of two seemingly unnatural units,
one to represent the class of permanent storage tanks, and the other to
describe the type permanent storage tank. Another problem is that the
slots on that TypicalPermanentStorageTank are really supposed to contain
default values of these p.s.t.s, not definitional one. Another solution,
which makes these things explicit, uses a (universal) variable: (It also
spares us from having to create the fairly unnatural
...PermanentStorageTanks units)
AnyStorageTank
Description: This represents the class of all permanent storage tanks
UnivElements: (x)
x
UnivIsa: (AnyStorageTank)
MyDefiningSlots: (UnivIsa TimeOfStorage)
MyAssertionalSlots: (Diked?)
Description: All facts stored here are true for ALL p.s.t.'s.
TimeOfStorage: Permanent
Diked?: T
The slots of the x unit above indicate that x is defined as a universally
quantified member of AnyStorageTank which is permanent. Furthermore, each
such member is diked. In predicate calculus:
∀x. x:UnivIsa = (AnyStorageTank) & x:TimeOfStorage = Permanent
=> x:Diked? = T
The matching algorithm knows to examine the set of
AnyStorageTank:UnivElements whenever some question is asked concerning
members of some subset of this class.
***** Fact # 3.*****
3. Oil spilling into water causes a sheen.
Here we need the oft-lampooned event units:
Event#1
Description: This refers to the event of oil spilling into water.
GenlE: (Event#3, ...)
CausesE: (Event#2)
Substance1: Oil
Substance2: Water
Event#2
Description: This refers to the event of a sheen forming on water
GenlE: (Event#4, ...)
CausedByE: (Event#1)
OnSubstance: Water
Appearance: Sheen
For perspective, we include a few over the more general units, referred to above:
Event#3
Description: This refers to the event of one fluid enterring another.
GenlE: (Event#5, ...)
SpecE: (Event#1, ...)
Substance1: [Any fluid]
Substance2: [Any fluid]
Event#4
Description: This refers to the event of some change in appearance of
some quantity liquid.
GenlE: (Event#3, ...)
SpecE: (Event#2, ...)
OnSubstance: [Any fluid]
Appearance: [Any feature]
The various event-relating slots, such as GenlE, SpecE, CausesE and
CausedByE, are already defined; (see bottom of page) and point to event
units which are more general, more specific, the results and causes of
some event unit. Note all of these may point to a set of values -- i.e. a
unit representing Event#2 would also qualify as a specialization of an
event referring to a sheen forming on some arbitrary liquid.
The slots Substance1 and Substance2 would have to be defined, as would
OnSubstance and Appearance. While we would not expect any general KB
(knowledge base) to come equipped with things as specific as Event#1 or
Event#2, we might expect to find something like Event#3, and almost
certainly Event#4. Even something like Event#4 is not as general as
possible - it specializes the ChangeInSomeSubstance event unit, for
example.
Two final comments: 1) The Event#2-- units are by no means the limit of
specificity: It is more general than OilFromPipe93SpillingIntoWOC, which,
in turn, can be further restricted into
MachineOilFromPipe93SpillingIntoWOCAfterOutFall93, (which can be
restricted to DayOldMachineOil#2FromPipe93'sFirstOutletSpillingIntoWOC-
AfterOutFall93onAug23, ...) The second point, which was never conveyed
during the workshop, was that these units are not simply produced
arbitrarily. The idea is, whenever you have something to say about some
event, one can then create a unit to hold this information. If the fact
is general, it should go on a general event unit, which enables its
descendants to inherit these facts, via the GenlE link. For example, we
need to store the fact that "Oil spilling into water causes a sheen" just
once, (shown above); and we will now expect to find a sheen on every water
area associated with each more specialized unit.
Each of the slot types SpecE, GenlE, CausesE and CausedBy have the same
basic form: e.g.:
GenlE
Description: This points from an event to those events which are more
general -- i.e. have fewer specifics specified.
Datatype: [Descendant of AnyEvent]
Format: [Set of values]
MakeSenseFor: [Descendant of AnyEvent]
Inverse: SpecE
***** Fact # 4.*****
4. The types of countermeasures taken are a boom at Wier1 and skimmer at
Wier2.
Here we can use the same event units, using the PreventedByE slot to point
from this problem (which requires these countermeasures) to the list
(Event#8 Event#9).
(Note PreventedByE:Inverse = InhibitsE.)
Event#7
Description: This is the problem which necessitated these countermeasures
- eg an oil spill at some location.
PreventedByE: (Event#8 Event#9)
Event#8
Description: Place a boom at Wier1.
InhibitesE: (Event#7)
GenlE: (Event#10)
Object: Boom#003
Location: Weir1
Event#9
Description: Place a skimmer at Wier2.
InhibitesE: (Event#7)
GenlE: (Event#11)
Object: Skimmer#005
Location: Weir2
For context, we include the more general event units:
Event#10
Description: Place a boom somewhere.
SpecE: (Event#8)
GenlE: (Event#12)
Object: [Any Boom]
Location: [Any Location]
Event#11
Description: Place a skimmer somewhere.
SpecE: (Event#9)
GenlE: (Event#12)
Object: [Any Skimmer]
Location: [Any Location]
Event#12
Description: Place an object somewhere.
SpecE: (Event#10 Event#11)
Object: [Any Object]
Location: [Any Location]
***** Fact # 5.*****
5. Oil sometimes spills out of broken machinery.
The real problem here is the modality "sometimes". To represent this, we
use the PossiblyCausesE (resp. PossiblyCausedByE) type of slot, which is
analogous to the CausesE (resp. PossiblyCausesE) type of slot; and, in
fact, y ε x:CausesE => y ε x:PossiblyCausesE. (resp. y ε x:CausedByE =>
y ε x:PossiblyCausedByE). Of course, PossiblyCausesE:Inverse =
PossiblyCausedBy.
Event#13
Description: The event of a machine breaking.
PossiblyCausesE: (Event#14)
GenlE: (Event#15)
AffectedObj: [Any machine]
WhatHappened: "It broke"
Event#14
Description: The event of oil spilling from a machine.
PossiblyCausedByE: (Event#13)
GenlE: (Event#17)
Substance: [Any oil]
FromLocation: [Any machine]
As usual, the more general objects:
Event#15
Description: The event of some object breaking.
GenlE: (Event#16)
SpecE: (Event#13)
AffectedObj: [Any object]
WhatHappened: "It broke"
Event#16
Description: The event of something spontaneously happening to an object.
i.e NOT due to some external reasons
(so "old age" would qualify)
SpecE: (Event#13)
AffectedObj: [Any object]
WhatHappened: "It broke"
Event#17
Description: The event of some liquid spilling.
GenlE: (Event#18)
SpecE: (Event#14)
Substance: [Any liquid]
FromLocation: [Any location]
***** Fact # 6.*****
6. Many inventory lists are incomplete.
Here, the problem is with the "many" modifier.
A solution which begs that subissue is:
AnyInventoryList
Description: This represents the class of all inventory lists.
IntentionalSubClass: (AnyIncompleteInventoryList)
AnyIncompleteInventoryList
Description: This represents the class of all incomplete inventory lists.
SuperClass: (AnyInventoryList)
TypicalExample: TypicalIIL
RelativeSize: Many
MyDefiningSlots: (SuperClass TypicalExample)
MyAssertionalSlots: (RelativeSize)
TypicalIIL
Description: This represents a typical incomplete inventory list.
TypicalExampleOf: AnyIncompleteInventoryList
Complete?: False
The semantics of IntentionalSubClass implies AnyIncompleteInventoryList ⊂
AnyInventoryList, and each member has some additional constraints. (This
same mechanism could have been used to state that, say, 83%, of all
inventory lists are incomplete.)
***** Fact # 7.*****
7. Water flows through a pipe at 0.5 ft/sec.
TypicalPipe
Description: This represents the typical pipe.
TypicalExampleOf: AnyPipe
FlowRate: 0.5 ft/sec
Purist may argue that all I've stated is that the default speed of water
flow is 0.5ft/sec. Well, that depends on the definition of FlowRate --
perhaps this slot is defined such that the value of U:FlowRate is the
value of T:FlowRate, where T is the prototypes (i.e. nearest appropriate
typical example) to U, whenever U is an individual; or otherwise the value
actually stored on the U unit otherwise.
Alternatively, we could create a new variable, x, which is a "universal
member" of AnyPipe, and show here that the flow rate is necessarily
0.5ft/sec:
AnyPipe
Description: This represents the class of all pipes.
UnivElements: (x)
x
UnivIsa: (AnyPipe)
MyDefiningSlots: (UnivIsa)
MyRefiningSlots: (FlowRate)
Description: Facts stored here are true for ALL pipes.
FlowRate: 0.5 ft/sec
***** Fact # 8.*****
8. If the chemical is HF, then tell the observer not to breathe it.
Rule#332
Isa: (AnyRule)
IfTrulyRelevant: ((EQ 'Chemical `HF))
ThenTellUser: "Do not breath chemical!!"
Priority: High
OnTask: ImminentDanger
ImminentDanger
Description: This task tries to find if the current situation is
dangerous; and if so, suggest solutions/fixes/alternatives.
Isa: (AnyTask)
RuleList: (Rule#332, ...)
Of course, to see how this would work would require showing the interpreter
which would process this rule
(as well as the interpreter used for this task).
This information is stored explicitly (and fairly declaritively) on various
units -- for example, TypicalTask and TypicalRule have expressions which serve
as default values for the components of such functions,
while the units which represent various
slots, such as HowToProcess, describe the details relating how to assemble these
functions. See the RLL memo [Greiner] for further specifics.
***** Fact # 9.*****
9. When attempting to find the source of a spill in the creek, look for the
chemical in the manhole nearest the creek.
LocateSource
Isa: (AnyTask)
Description: This task tries to find the source of a spill.
RuleSet: (Rule#209...)
Rule#209
Isa: (AnyRule)
OnTask: (LocateSource)
Description: This rule suggests how to find the source, by looking in
an appropriate manhole.
IfPotentiallyRelevent: ((Unknown 'SourceLoc))
IfTrulyRelevent: ((EQ 'SpillObserved 'Creek))
ThenTellUser: "Look in the manhole nearest the creek."
NOTE: If the purpose of the rule was to actually determine which manhole to examine,
it might make sense to change Rule#209 by replacing its ThenTellUser with
"Look in the manhole nearest the creek. I'll tell you which manhole in a second."
and adding the slot
ThenAddToAgenda: (FindBestManhole),
where FindBestManhole is a task which will tell the user which manhole to examine,
if necessary.
***** Fact # 10.*****
10. For all oil spills, if there are limited human resources, do the containment
before locating the source.
Rule#261
Description: This is used to order tasks, for the spill problem.
IfPotentiallyRelevant: [AND (Trying to order tasks)
(This is a spill problem)]
IfTrulyRelevant: ((EQ 'ManPower 'Limited)
(EQ 'SpillType 'Oil))
ThenOrderTasks: [Put Containment before LocateSource]
OnTask: OrderTasksForSpillProblem
Specificity: 200
Containment
Description: This task suggests ways to contain a spill.
Isa: (AnyTask)
Priority: 369
LocateSource
Description: This task tries to find the location of a spill.
Isa: (AnyTask)
Priority: 44
OrderTasksForSpillProblem
Description: This system-level task is responsible for ordering the tasks run.
Note it is in another, meta-level, bin from the other
tasks, and so its priority level is incomparable with theirs.
Isa: (AnyTask)
Priority: 210
[Specificity will be defined on the next page.] In fact, Rule#261 might
have been derived from a more general heuristic, which suggested
performing the more urgent things before the less timely; and noting this
heuristic is especially relevant when there is reason to believe not all
of the tasks will get a chance.
Rule#21
Description: This is used to order tasks.
IfPotentiallyRelevant: [AND (Trying to order tasks)
(Not all tasks will be done)]
ThenOrderTasks: [Put tasks in order of ascending priority.]
Note the "Priority" slot may be computed from a host of things. It
should, for example, use the fact that the spill type is oil in its
calculation; such that the the relative Priority of Containment is higher
than LocateSource. In fact, some rule like Rule#261 might even be
detrimental in cases where you need to determine the source to learn of
the type of spill, as this rule might end up postponing this spill
location task.
Better whould be using the priority scheme as it stands, and have Rule#261
simply increase the value of Containment:Priority, whenever the spill is
oil; and increase it more when human resources are scarce.
Needless to say, much of the smarts of this comes from the fact that
EURISKO, (on top of RLL,) knows when to run these various rules - but this
too is described in the units, (as well as in the RLL memo [Greiner].)
***** Fact # 11.*****
11. If the spill is gushing, locate the source before trying to contain it.
Again, the difficulty of this rule is primarily in assuring that it be
called in correct time -- ie when deciding which task to next run. This,
of course, requires knowledge of how the interpreter must work - as one of
the interpreter's chores is finding the rules necessary to determine which
tasks to process, and in what order. Modulo this, we would represent the
above fact:
Rule#443
Description: This is used to order tasks, for the spill problem.
IfPotentiallyRelevant: [AND (Trying to order tasks)
(This is a spill problem)]
IfTrulyRelevant: ((EQ 'CurrentState 'Gushing))
ThenOrderTasks: [Put Locatesource before Containment]
OnTask: OrderTasksForSpillProblem
Specificity: 523
Things like the conflict resolution scheme become important if ever both
this Rule#443 and the earlier Rule#261 are triggered. One solution would
be to use the more specific. So here, seeing Rule#443:Specificity = 523 is
greater that Rule#261:Specificity = 200, we take Rule#443's advice over
Rule#261. This specificity should be calculated - but how to do that is
another problem. (Alternatively we could assign such values statically,
for a simpler, but less interesting solution.)
Again, it would seem better to use the approach mentioned in the previous
page; which, here, would have Rule#443 actually diminish the Priority of
Containment as one of its Then parts; rather than use the ThenOrderTasks.
Rule#443 was shown in the form above only because this is a "direct
translation" of the fact posed.
Note that in RLL all of these schemes can be implemented; and the user is
left only with the task of deciding which is the most appropriate -- as
opposed to how can I bend the single control system to accomodate this
statement.
***** Fact # 12.*****
12. If a flammable liquid is spilled, call the fire department.
This is fairly straightforward:
Rule#391
Description: This suggests calling the fire dept if liquid flammable.
IfPotentiallyRelevant: ((Known 'SpilledLiquid))
IfTrulyRelevant: ((Apply 'Flammable 'SpilledLiquid))
ThenTellUser: "Call fire department!"
OnTask: ImminentDanger
Specificity: 854
***** Fact # 13.*****
13. Any two sources will flow into a common pipe.
I interpret this fact as meaning:
∀ s1, s2 ε Sources. ∃ p0 ε Pipes. FlowInto(s1 p0) & FlowsInto(s2 p0).
AnySource
Description: This refers to the class of all sources.
UnivElements: (s1 s2)
AnyPipe
Description: This refers to the class of all pipes.
ExistElements: (p0)
p0
Description: This is the skolem variable, p0 = f(s1, s2) mentioned above.
ExistIsa: (AnyPipe)
FlowsFrom: (s1 s2)
SkolemOf: (s1 s2)
MyDefiningSlots: (ExistIsa FlowsFrom)
s1
Description: This is one of the sources mentioned above.
UnivIsa: (AnySource)
FlowsInto: p0
MyDefiningSlots: (UnivIsa)
s2
Description: This is the other source mentioned above.
UnivIsa: (AnySource)
FlowsInto: p0
MyDefiningSlots: (UnivIsa)
Note - ExistIsa and ExistElements are the existential counterparts to
UnivIsa and UnivElements.
***** Fact # 14.*****
14. There's a tank outside building 3035 with a dike around it.
I interpret this data as meaning
∃ t1 ε Tank. Outside(t1 B3035) & Dike?(t1 T).
AnyTank
Description: This refers to the class of all tanks.
ExistElements: (t1)
t1
Description: This is that tank.
ExistIsa: (AnyTank)
OutsideBldg: B3035
Diked?: T
MyDefiningSlots: (ExistIsa OutsideBldg Diked?)
A second interpretation is
∀ t1 ε Tank. Outside(t1 B3035) => Dike?(t1 T).
AnyTank
Description: This refers to the class of all tanks.
UnivElements: (tu)
tu
Description: This is any tank outside building 3035.
UnivIsa: (AnyTank)
OutsideBldg: B3035
MyDefiningSlots: (UnivIsa OutsideBldg)
MyAssertionalSlots: (Diked?)
Diked?: T
Note this confusion is a linguistic problem, due to English's imprecision.
***** Fact # 15.*****
15. Rain onto oil-contaminated soil causes oil flushing.
Back to events:
Event#18
Description: This refers to rain on oil-contaminated soil.
CausesE: (Event#19)
Event#19
Description: This refers to oil flushing.
PossibleCausesE: (Event#18 ...)
We could add the usual context - eg rain on soil, which is more specific
than rain on ground, which is a special case of water on solid surface;
but such a digression should not be necessary anymore.
***** Fact # 16.*****
16. The types of oil stored in building 3035 are X, Y, and Z.
B3035
Isa: (AnyBuilding)
Description: This refers to building 3035.
HousesOils: (X Y Z)
X
Isa: (AnyOil)
HousedIn: B3035
Y
Isa: (AnyOil)
HousedIn: B3035
Z
Isa: (AnyOil)
HousedIn: B3035
I suspect this question was asking about some trickier sort of thing --
dealing perhaps with quantities of fluid entities. However, unable to
determine what exactly that was, ...
***** Fact # 17.*****
17. Buildings in WOC-6 basin are 3035, 3022, and 3195.
This fact could be physically stored on the WOC-6 unit,
if there is a great need for this particular fact.
Alternatively, it could be "virtually" there - that is, derivable whenever
anyone asks for this fact, but absent until then.
A way of combining both would use the "BuildingsInBasin" virtual slot, which
has an algorithm describing how to fill in its value:
WOC-6
Isa: (AnyOutFall)
BuildingsInBasin: (B3035 B3022 B3195)
BuildingsInBasin
Isa: (AnySlot)
Definition: [Here is a specification describing how to determine
the value of U:BuildingsInBasin, given U, a unit
which represents an outfall.]
***** Fact # 18.*****
18. Container 86 has a capacity of 100 gallons and usually empties at a
rate of 2 gallons/day.
The obvious question about this fact is what the "usually" modifier is meant
to mean.
Interpretation 1: The emptying-rate is a function of the amount of fluid
which is now in the container; and the average of all volumes
(perhaps weighted by the frequency of occurance) is 2 gallons/day.
Interpretation 2: Left to itself, the emptying rate will be 2 gallons/day.
However, if some pump is extracting the content, that rate will be
more; or if some pump is adding fluif, that rate will be less.
By cases, the solutions are
Case 1:
Container86
Capacity: 100 gallons
EmptyingRate: ?
CurrentFilledVolume: y
EmptyingRate
Isa: (AnySlot)
Definition: [To compute U:EmptyingRate, apply Fn#803
to U:CurrentFilledVolume.
If this value is fairly stable, consider caching this value
in U:EmptyingRate. Otherwise don't bother.]
Case 2:
Container86
Capacity: 100 gallons
EmptyingRate: (SeeUnit EmptyingRateOfContainer86)
MitigatingCircumstances: y
EmptyingRateOfContainer86
Description: This subunit is devoted to storing information about
the value of the EmptyingRate of Container86.
*vaLue*: ?
UsualValue: 2 gallons/day
ToComputeValue: [Examine Container86:MitigatingCircumstances to determine
whether the value should be the default, of 2 gallons/day,
or some other value.]
Note the existing retrieval functions will do the right things with this SeeUnit
pointer to a subunit. (The smarts for this is in the "SeeUnit" unit, of course.)
There is no reasons the above two cases could not be combined, if that is
called for.
***** Fact # 19.*****
19. If the person doing the backtracking can no longer see the chemical, stop
backtracking.
Rule#555
Isa: (AnyRule)
OnTask: BackTracking
IfPotentiallyRelevant: ((Unknown 'SourceLocation))
IfTrulyRelevant: (AND [All potential sights have been checked]
[Chemical not found] )
ThenTellUser: "Lost the trace. Stop backtracking."
"(Unless you are sure about all the locations you've reported, start
backtracking, in AI sense.)") )
ThenControl: [Terminate BackTracking task, with failure]
***** Fact # 20.*****
20. If you want to find the source of the spill, select a person to look for it.
Rule#666
Isa: (AnyRule)
OnTask: LocateSource
IfPotentiallyRelevant: ((Unknown 'SourceLocation) )
ThenAddToAgenda: (SelectUser)
SelectUser
Isa: (AnyTask)
Description: This task is responsible for selecting some one to look for
the source of a spill.
RuleSet: ...
***** Fact # 21.*****
21. There is a trade-off between the severity of the hazard and the number of
simultaneous tasks attempted: the more severe, the more tasks.
[This is a trade off?]
Rather than explicitly represent this relation, I would prefer to
de-compile this down to more primitive facts: For example, we could
assign an importance weight to the task at hand; and use this importance
weight to determine the number of simultaneous tasks to attempt. This
importance measure would, in turn, be based on the severity of the current
hazard - to realize the above condition. This could be stated more
directly by showing that the severity-of-hazard to importance-weight
function is monotonically increasing; as is the importance-weight to
nummber-of-simultaneous-tasks function. The basic inferencing algorithm
would then reason that their composition would be monotonic as well; which
is the "trade-off" condition. SeverityOfHazard Isa: (AnySlot)
Description: This maps a task to a numeric value, which indicates how
severe the current hazard is.
ImportanceMeasure
Isa: (AnySlot)
Description: This maps a task to a numeric value, which indicates
how importance this task is to attempt/succeed.
HighLevelDefn: (Composition SH-IM SeverityOfHazard)
Definition: (λ (u) (SH-IM (GetValue u 'SeverityOfHazard))
NumberOfSimulTasks
Isa: (AnySlot)
Description: This indicate how many subtasks we can justify assigning
at once.
Definition: (λ (u) (IM-NoST (GetValue u 'ImportanceMeasure))
SH-IM
Isa: (AnyFunction)
Description: This function maps from SeverityOfHazard to
ImportanceMeasure, for a given task.
Definition: (λ (x) [...]
Monotonic? Increasing
IM-NoST
Isa: (AnyFunction)
Description: This function maps from ImportanceMeasure
NumberOfSimulTasks, for a given task.
Definition: (λ (x) [...]
Monotonic? Increasing
***** Fact # 22.*****
22. If two people's description of a spill are inconsistent, prefer the second
description.
To represent:
∀ sd1, sd2 ε SpillDescript. AppliesTo(sd1 ThisProblem) & AppliesTo(sd2 ThisProblem)
& Inconsistent(sd1 sd2) =>
IF [(GetValue sd1 'TimeRecorded) > (GetValue sd2 'TimeRecorded)]
THEN Believe( sd1 )
ELSE Believe( sd2 ).
[This intentionally does NOT address the question of how to determine when
two descriptions are inconsistent.]
MostRecentDescription
Isa: (AnySlot)
Description: This slot returns the single description to be believed.
HighLevelDefn: (ApplyingFn CAR (PutInOrder AllDescriptions TimeRecorded))
Note the (PutInOrder AllDescriptions TimeRecorded) returns a function
which takes a unit, u, as an argument, and returns a list of the values,
(v1 ... vN), where each vi appeared in u:AllDescription, and where i>j =>
vi:TimeRecorded > vj:TimeRecorded. Taking the CAR of that returns the
most recent description.
This also does not consider performing this process only when two
descriptions are inconsistent - this could be acheived using the following
rule:
Rule#452
Isa: (AnyRule)
OnTask: SpillCharacterization
IfTrulyRelevant: ((Apply 'Inconsistent 'AllDescriptions))
ThenModifyUnit: [Use the value of uContext:MostRecentDescription rather
than uContext:AllDescriptions]
***** Fact # 23.*****
23. The OHMTADS mnemonic for corrosiveness is "COR".
Corrosiveness
Isa: (AnyProperty)
OHMTADSmnen: "COR"
***** Fact # 24.*****
24. Fuel oil spills often come from construction equipment.
1.
Rule#231
Description: This says to suspect construction equipment if some
fuel oil is found.
IfPotentiallyRelevant: ((Isa 'SpilledLiquid 'AnyFuelOil))
IfAskUser: "Has there been any construction equipment around there
recently?"
ThenTellUser: "That piece of equipment might have spilt that oil."
2.
We could first have written a general rule, which indicated
"IF SubstanceX is part of ObjectY,
AND SubstanceX is found out of place
AND ObjectY had been around that place
THEN Suspect ObjectY is source of SubstanceX."
With this, some knowledge that spills are liquids out of place, and the following
units, we might have expected EURISKO to build up Rule#231.
AnyConstructionEquipment
Description: This describes the class of construction equipment.
TypicalExample: TypicalCE
TypicalCE
Description: This refers to a typical piece construction equipment.
TypicalExampleOf: AnyConstructionEquipment
Components: [Fuel oil, nuts, bolts, ...]
3. A third solution uses Events:
Event#20
Description: The event of construction equipment being around.
PossiblyCausesE: (Event#21)
PossiblyCausesE*: (Event#21 Event#22)
Event#21
Description: The event of FUEL oil spilling from construction equipment.
PossiblyCausedByE: (Event#20)
PossiblyCausesE: (Event#22)
GenlE: (Event#14)
Substance: [Any fuel oil]
FromLocation: [Any piece of construction equipment]
Event#22
Description: The event of finding a Fuel Oil Spills.
PossiblyCausedByE: (Event#21)
For context, we include the Event#14 which was used for Fact 6 also.
Event#14
Description: The event of oil spilling from a machine.
PossiblyCausedByE: (Event#13)
GenlE: (Event#17)
Substance: [Any oil]
FromLocation: [Any machine]
Finally, PossiblyCausesE* is the transitive closure of the PossiblyCausesE relation.
***** Fact # 25.*****
25. Attempt to minimize the number of persons called on-site.
The general problem solving strategy is as follows:
1. Find all feasible solution plans.
2. Select the one the best plan, and execute that.
[Note this will be true for sub-parts of this plan as well.]
Step 2. can be done by the Definition of BestPlan -
BestPlan
Isa: (AnySlot)
Description: This selects from P:AllPlans (where P is a problem to be
solved) the best member -- ie the value of sεP:AllPlans
which maximizes the value of s:GoodNess
HighLevelDefn: (ApplyingFn MAX AllPlans)
This requires a sophisticated GoodNess slot -
GoodNess
Isa: (AnySlot)
Description: This assigns to each solution plan, s, a numeric value.
Note this measure varies from class of problem to class
of problem.
HighLevelDefn: (OneOf SpillProblemGoodNess ... )
SpillProblemGoodNess
Isa: (AnySlot)
Description: This assigns a numeric value to each SPILL solution plan, s.
HighLevelDefn: (VariesWith (ApplyingFn MINUS PeopleCalledOnSite) ...)
Definition: (λ (u ) [... when u refers to a spill problem, lower
u:GoodNess as u:PeopleCalledOnSite increases....]
Note - OneOf, VariesWith and ApplyingFn are all slot combiners,
which each does the appropriate thing.
Note this shows that ONE criteria for selection is consideration of the number
of people called on site (this PeopleCalledOnSite slot, of course, must be defined
as well.)
***** Fact # 26.*****
26. If a heuristic calls for an action you can't currently perform, ignore
the heuristic.
[Should we descriminate between heuristics & hard-and-fast rules?
I'm assuming not.]
The function which actually interprets the various rules is itself built from
(meta-)rules, which should include this one (at least when considering
each SPILL rule.)
Rule#M325
Isa: (AnyMetaRule)
IfPotentiallyRelevent: [Currently considered rule is for a Spill rule]
IfTrulyRelevent: [(CannotDo 'ThenDoAction)]
ThenTellUser: (CONCAT "I'm not even considering the " uThisRule
" rule, as I can't perform its action, anyway.")
ThenModifyRuleSet: [Delete uThisRule from current rule set.]
AnyMetaRule ⊂ AnyRule
***** Fact # 27.*****
27. If a hazardous substance has spilled, don't worry about human resource
limitations.
Basically, this Rule#777 instructs the SpillProblemGoodNess to ignore the value
of the problem's PeopleCalledOnSite slot when the substance is hazardous.
Rule#777
Isa: (AnyRule)
OnTasks: [Every SPILL task]
IfPotentiallyRelevant: ((Apply Harzardous? 'Substance) )
ThenModifyUnit: [Redefine PeopleCalledOnSite so it always returns
"Irrelevant"]